perm filename TODO.TXT[PNT,HE]6 blob sn#359470 filedate 1978-06-05 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002		FEATURES TO BE ADDED TO POINTY
C00004 00003		FUTURE OF POINTY 	- 	APRIL 6, 1978
C00009 ENDMK
CāŠ—;
	FEATURES TO BE ADDED TO POINTY


			MAJOR
1)	MACROS
*	a)	macro record
*	b)	parser changes
	c)	throw into input stream
*	d)	macro definition
2)	SIMULATION OF ARM MOTION WHEN ELF UNAVAILABLE
3)	IMPLICIT ARGUMENTS FOR EXPRESSIONS
4)*	DIRECT EXECUTION OF INSTRUCTIONS FROM SOURCE FILE
5)	DIMENSION CHECKING
6)	SAVE CONTEXT OF THE WORLD ON THE DISK FILE IN CASE USER CRASHES
	SYSTEM OR FOULS UP
7)	MULTI-SEGMENT MOVES
8)	FORCE SENSING
9)	CONTROL STATEMENTS AND BLOCK STRUCTURE
10)	MACRO LIBRARY
11)	INTERNAL FORM OF FILE STORAGE FOR FAST I/0 without going through parser.
12)*	FUNCTION EXPRESSIONS WITHOUT PUTTING SOURCE TEXT THROUGH THE SCANNER

			MINOR
1)*	PRINT OUT DEFAULT MOVES ON SCREEN
2)	READARM BEFORE MOVEZ, MOVEX, ETC
3)	VALUE OF PI
4)	RADIAN FUNCTIONS
5)*	PRINT OUT DEVICE BLOCK WORDS CORRECTLY
6)*	PROMPT
7)	PAUSE
8)	PRINT VARIABLES ON BASIS OF LAST REFERRED TO
9)*	NODISPLAY, REDISPLAY, DISPLAY SCALARS
10)	CHANGE TO SYNTAX OF WRITE STATEMENT
		WRITE <var_LIST> INTO <file>
		WRITE INTO FILE
		WRITE ALL INTO FILE
		WRITE <var_list>
		WRITE SCALARS
		WRITE MACROS
	FUTURE OF POINTY 	- 	APRIL 6, 1978

	The next stage in the evolution of POINTY is the implementation
of macro facilities which enables the user to define his own
macros, with parameters if possible.  These macros will be simple
text substitution macros.  At this time we don't anticipate putting
in the full macro capabilities of SAIL.
After this is implemented, we will define a set of commonly used macros
that help the user to accomplish sequences of instructions like
LOCATE.

	The role of functions and subroutines have not been fully
defined yet; if implemented, they will not have any counterpart in
AL.  They will have the effect of variables proposed by the Ginis.
At the same time, they permit the user to accomplish things
not possible in macros (e.g. return values), 
and allow the storage of internal forms of expressions.  
The use of an internal form will be particularly useful
when we have swapping of modules.  The increase of data space is
offset by not having to call the parser as many times.
While we are doing this, we should consider
the ability to store information in an internal
form which makes file i/o faster to accomplish.  Such i/o of course can only be
to files written by POINTY which are not tampered with by the user.
This is contingent upon writing our own interpreter.
For a start, implementation of simple expression functions will be done to
evaluate the problems that crop up.


	The implementation of multi-segment moves, force compliance and
force sensing appears to be worthwhile, especially if we want to use 
POINTY as a means of trying out and debugging AL statements.  Multi-segment
moves should be implemented first, and they should take into account
via points, approach and deproach points, in addition to doing
several simple move statements consecutively.

	The treatment of block and control structure is next.
At what level should we execute instructions?  Should they be
done in terms of simple statements, or do we only strip off the
outermost BEGIN-END tokens?  In the case of inner blocks, do we
parse the whole block, or parse it statement by statement?
How will this affect IF..THEN..ELSE and WHILE...DO.. and a possible 
DO ... UNTIL ... statment?
Maybe we should restrict control statements to only simple statements.
The introduction of the control statements means expanding the
expression evaluator to handle boolean expressions in addition to
arithmetic expressions.
How can we handle COBEGIN-COEND statements?

	Other features we might want are the PAUSE and
PROMPT commands.  The PROMPT command seems particularly relevant
for the case where source programs are input from disk files.


ULTIMATE AMBITION -
	POINTY reads in an AL source file and executes it statement
by statement, and after each successful execution copies it out on a disk
file.  When there are errors, the user is given the option of
hot editing the statement which POINTY will execute and if
successful will write into a disk file.  At the end of the POINTY
session there will be a correct running AL program which
does not cause grief to the AL compiler.